This description relates to radio network control.
High Data Rate (HDR) is an emerging mobile wireless access technology that enables personal broadband Internet services to be accessed anywhere, anytime (see P. Bender, et al., “CDMA/HDR: A Bandwidth-Efficient High-Speed Wireless Data Service for Nomadic Users”, IEEE Communications Magazine, July 2000, and 3GPP2, “Draft Baseline Text for 1xEV-DO,” Aug. 21, 2000). Developed by Qualcomm, HDR is an air interface optimized for IP packet data services that can deliver a shared forward link transmission rate of up to 2.46 Mbit/s per sector using only (1×) 1.25 MHz of spectrum. Compatible with CDMA2000 radio access (TIA/EIA/IS-2001, “Interoperability Specification (IOS) for CDMA2000 Network Access Interfaces,” May 2000) and wireless IP network interfaces (TIA/EIA/TSB-115, “Wireless IP Architecture Based on IETF Protocols,” Jun. 6, 2000, and TIA/EIA/IS-835, “Wireless IP Network Standard,” 3rd Generation Partnership Project 2 (3GPP2), Version 1.0, Jul. 14, 2000), HDR networks can be built entirely on IP technologies, all the way from the mobile Access Terminal (AT) to the global Internet, thus taking full advantage of the scalability, redundancy and low-cost of IP networks.
HDR has been adopted by TIA (Telecommunications Industry Association) as a new standard in the CDMA2000 family, an EVolution of the current 1xRTT standard for high-speed data-only (DO) services, formally referred to as HRPD (High Rate Packet Data), also known as 1xEV-DO or IS-856.
IS-856 systems are typically implemented using the radio access network architecture shown in FIG. 1. Here the Access Terminal (AT) 10 may be a laptop computer, a Personal Digital Assistant (PDA), a dual-mode voice/data handset, or another device, with built-in IS-856 support.
The entire administrative service area of a wireless access provider may be divided into one or more subnetworks (or subnets) 12, 14. Each subnet 12 includes a set of Radio Nodes (RN's) 16, 18 and one or more Radio Network Controllers (RNC) 20, 22. The RN's are connected to RNC's over a backhaul network 24. In existing 2G and 3G wireless networks, each RN is connected to only one RNC using dedicated leased lines or ATM permanent virtual circuits (PVC's). Further, RNC's are connected to each other using dedicated leased lines or ATM PVC's. In a new generation of IP-based radio access networks, the backhaul can be implemented using a shared IP or metropolitan Ethernet network which supports many-to-many connectivity between RN's and RNC's.
Each RNC typically controls 25–100 RN's. Each RN typically supports 1–4 carriers each of 1.25 MHz of bandwidth. Further, each cell area (not shown) is typically divided into multiple sectors (typically 3 or 6) and the RN has one radio transceiver 27 for each sector.
Each RNC is connected over an IP network 26 to one or more Packet Data Serving Node's (PDSN's) 28 (see TIA references cited earlier). The RNC communicates with the PDSN over a standard interface termed the R-P (Radio-Packet) interface 30. The R-P interface is further broken into two interfaces: the A10 interface used to carry data and the A11 interface used to carry signaling. A PDSN can be viewed as an edge router that supports mobility; it maintains link layer connectivity to AT's through the Access Network. The PDSN also interfaces to AAA servers 32 for Authentication, Authorization, and Accounting (AAA).
Once an AT connects to the network, it establishes session with an RNC and receives a link layer address from the RNC. The session represents all the information the RNC needs to serve the AT. In IS-856 radio access networks as currently defined by 3GPP2 in 1xEV-DO IOS Phase 1 (IS-878), each RN is uniquely associated with an RNC and each subnet contains only one RNC. As a result, when an AT moves from the coverage area of one RNC to the coverage area of another, the AT performs a handoff, which includes a session transfer.
Every time a dormant AT crosses a subnet boundary, the AT initiates a dormant handoff by sending a UATI_Request. The AT recognizes the need for a dormant handoff by monitoring the 128-bit SectorID being broadcast by the sectors. All sectors that belong to the same subnet have SectorID's that fall within a certain range. The 128-bit Universal Access Terminal Identifier (UATI) assigned to an AT in a given subnet falls within the same range. When the AT moves into the coverage area of another subnet, the AT compares its UATI with the SectorID being broadcast by its serving sector. When these do not belong to the same range, the AT knows that it has crossed a subnet boundary and initiates the dormant handoff by sending a UATI_Request.
A first purpose of a dormant handoff is to inform the PDSN to send packets arriving for that AT to the new serving RNC. Dormant handoffs involve a relocation of the R-P (A10) session from the old serving RNC to the new serving RNC. Without such handoffs, the PDSN would send packets to an old serving RNC. Since the old serving RNC does not know the location of the AT outside its subnet, AT's packets may be lost.
A second purpose of a dormant handoff is to transfer session information between RNC's. In IS-856, each RNC maintains certain session information about the AT. Such session information is needed for communication over the air interface. Session information includes the Universal Access Terminal Identifier (UATI), security keys for access channel authentication and encryption, and other protocol constants. Every time the AT crosses an RNC boundary (in this case a subnet), a new UATI needs to be assigned to the AT and the remaining session information needs to be transferred from the old serving RNC to the new serving RNC. Such a transfer requires a network link between the RNC's. Without such session transfer, every handoff between RNC's would result in a new and lengthy session establishment, taking up precious air resources and causing delays. When the footprint of an RNC is small, dormant handoffs occur frequently, resulting in excessive use of airlink resources (for the new UATI assignment), extra processing for the RNC's to implement the session transfer, and extra processing for the RNC and PDSN to relocate the A10 connection.
In CDMA2000 systems, mobility management is provided by the Mobile Switching Center (MSC)/Visitor Location Register (VLR). When an AT provides a location update to inform the network of its new location, this information is immediately forwarded to the serving MSC. Such location updates are provided by the AT when the it moves sufficiently away from the sector where it last provided a location update. When the PDSN receives a packet data for an AT, it sends the packet to the PCF. The PCF, recognizing that no traffic channel exists for this AT, in turn informs the RNC that last served this AT. That RNC then informs the MSC. The MSC, equipped with location information stored in the VLR, requests one or more RNC's to page the AT from a certain set of sectors. Once the AT responds with an Origination message to its serving RNC, the serving RNC sets up a so-called A8/A9 connection to the PCF. Soon after, the PCF starts forwarding the received packets to the serving RNC.
A similar procedure can be used in IS-856, by adding a similar PCF entity 50, as shown in FIG. 2. (A system like the one described here has been proposed in 3GPP2 for 1xEV-DO IOS Phase 2.) However, since IS-856 networks do not have an MSC, it is necessary to define a separate mobility management function (Mobility Manager 52) responsible for maintaining the location information for every AT that is being served by the RNC's under its control. Such a Mobility Manager can be integrated into the PCF, or can be a separate network entity. Any time the AT provides a location update by sending an IS-856 RouteUpdate message, its location information is immediately forwarded by the serving RNC to the Mobility Manager. When the PDSN receives a packet data for an AT, it sends the packet to the PCF, which in turn informs the Mobility Manager. The Mobility Manager, equipped with the location information requests, either directly or via the RNC that last received a location update from the AT, requests one or more RNC's to page the AT from a select set of sectors. Once the AT responds with a ConnectionRequest message, the serving RNC sets up a so-called A8/A9 connection to the PCF. Soon after, the PCF starts forwarding received packets to the serving RNC. This approach eliminates the need for relocating the A10 (R-P) session to the PDSN every time the AT crosses an RNC boundary, effectively expanding the size of the subnet to cover multiple RNC's.
The Mobility Manager function does not address the session transfer issue described earlier. For this purpose, another logical network element, a Session Manager 53 is introduced. Like the Mobility Manager, a Session Manager controls multiple RNC's, and maintains session information for all sessions handled by the RNC's that it controls. Like the Mobility Manager, the Session Manager may be a separate network element, may be combined with the Mobility Manager or may be integrated with the PCF.
When a new session is to be established, the serving RNC interacts with the Session Manager. The Session Manager provides the UATI to be assigned to the AT and stores the session parameters that the serving RNC has determined during the key exchange and configuration phases of the session set-up. Whenever the AT establishes a new connection with its serving RNC, the RNC retrieves the session information from the Session Manager. In the case where the Session Manager is integrated with the PCF, this can be accomplished during the A8/A9 connection set-up procedures. The RNC provides the latest session information back to the Session Manager when a connection is closed. Again, in the case where the Session Manager is integrated with the PCF, this can be accomplished during the A8/A9 connection tear-down procedures. Additional delays are caused by passing of session information back and forth between the Session Manager and the RNC during every connection set-up.